跳到主要内容

LLM 原理速览：Transformer、Attention 与“理解/推理/生成”

副标题：把架构直觉补齐——你在 LLM基础 里学的是怎么用；这里回答为什么它能像那样工作（前端向、够用深）。

目标：能向面试官/同事说清楚：自注意力在干什么、Token 从哪来、以及“像推理/像理解”的边界在哪里。

目录​

1. 先收束一句话​

  • 大语言模型在推理时做的事情：在已给出的上下文中，反复计算「下一个子词（Token）最像什么」的概率分布，采样出一个 Token，拼回去，再算下一步——像「高维自动补全」，只是补全的单元是子词、层数是几十层、参数规模是十亿/百亿级。
  • “懂上下文/会推理/能写长文”，主要来自：自注意力让任意位置能互相“看见并加权”、前馈层做非线性与模式混合、预训练/对齐把统计规律与指令风格压进参数；而不是一张图里真有一个可执行的“逻辑引擎”。

与 LLM基础 的衔接：那里讲 产品侧 的 token 预算、温度、RAG；这里讲这些现象背后的 结构直觉。

2. 文本生成在模型里长什么样：自回归 + 下一 Token 预测​

自回归（autoregressive）：用「已经生成的部分」来预测「下一小段」。在 LLM 里，这小段就是 1 个 Token（子词级）。

用伪代码看一次解码循环（与你在接口里调用的 max_tokens 对应）：

已见序列 = 用户输入与历史（经分词后）
for i in 1..max_tokens:
  分布 = 模型(已见序列)   // 在词表上得到概率
  下一词 = 采样(分布, temperature, top_p)  // 你设置的随机性
  已见序列 = 已见序列 + 下一词
  if 遇到结束符: break

所以流式输出（SSE）在工程上，就是把上面对「下一词」的循环逐步往外推。中断连接要能停住上游，否则还会继续烧 Token（服务端基础能力 里会反复遇到）。

3. Transformer 是什么：以 GPT 类「只解码器」为主​

经典论文中的 Transformer 有 Encoder 与 Decoder 两块；当前多数对话/补全大模型是 Decoder-only 堆叠（如 GPT 系列）。可把它记成：一串 同构的“块（Block / Layer）” 累加，每块里主要有两类计算：

  • 自注意力（把序列里各位置信息做「谁该多看谁」的混合）
  • 前馈网络 FFN（对每个位置做强非线性变换、特征混合）

块与块之间是残差 + 层归一化（你不必背公式，只要知道：它让很深的网络仍然可训练、梯度更稳）。

3.1 和“旧 RNN”的直观对比​

  • RNN/LSTM：更偏「沿时间步压缩」成隐状态，长距离依赖难、难并行训练。
  • Transformer：自注意力在一步里把任意两个位置拉到一起算关系，并行友好，更适合大规模预训练——这也是当代 LLM 的标配底座。

4. Attention / 自注意力：上下文的“可组合检索”​

4.1 直觉（不按公式证）​

对每个位置，模型都会构造三个角色（Query / Key / Value）：

  • 你可以把 Key 想成“这一位提供什么线索的标签”
  • 把 Query 想成“当前在找什么线索的提问”
  • Q 和 K 的匹配程度 决定权重；再用权重去混合 Value

这一整套叫 缩放点积注意力 的一种实现。所有位置并行做一遍，就得到每个位置看过全序列后更新过的表示，即 自注意力（Self-Attention）。

因此：

  • 所谓**“看上下文”**，在实现上很朴素：在算下一 Token 的分布之前，让当前层里的每个子词都经过一次和全句其他子词的“软对齐”。
  • 距离远的词也能直接连边，不依赖“一步一步传下去”，所以长程依赖比传统 RNN 更顺。

Multi-Head（多头）：多组 Q/K/V 并行，可理解为多视角的关联（指代、句法、主题、指代消解等不同子空间的分工），再拼起来给下一子层用。

4.2 和「检索 / RAG」的类比（仅类比）​

自注意力是在一段已编码的向量序列内部做软检索；RAG 是从外部语料取片段再塞进 Prompt。两者都带“找相关再组合”的味道，但层次完全不同：前者在模型内部、后者在产品架构上（见 LLM基础 - RAG）。

5. 位置从哪来：为什么打乱顺序会毁掉语义​

自注意力本身对位置不敏感（你互换两位，若 Q/K/V 从同一组向量来，几何关系可能很接近）。所以在真实模型里要加 位置信息（位置编码 / RoPE 等）：

  • 加在输入或乘在 attention 的投影上（视架构而定，面试答到“显式注入序信息”即可）
  • 没有位置信息，“谁在前谁在后” 就模糊，语法、指代、代码结构 都会崩

这也是 “上下文 = 有顺序的 Token 序列 + 可模型化的位置” 的原因。

6. Token 与分词：怎么切、怎么数、和计费的关系​

6.1 Token 从哪来​

Tokenizer 把原始字符串变成 ID 序列。现代模型常用 BPE / SentencePiece 类子词：

  • 英文：常见词 + 子词，1 个词可能是 1 或多个 Token
  • 中文：多数字符需要 1 个或多个子词 拼起来；所以 “1 字 ≈ 1 Token” 往往不成立（LLM基础 里的粗估是工程上估算成本用）

6.2 和 API 的 usage 对齐​

  • 计费/用量 以服务端的 tokenizer+模型定义为准；你本地的字符数/经验公式只能做预算，不能对账。
  • 同一段话在不同模型/不同 tokenizer 上 Token 数可以差很多（换模型要重新估预算）。

6.3 对前端的直接含义​

  • 限制输入框长度、历史条数、RAG 片段时，真正该守的是 API 的 token/字符策略，而不是“肉眼字数”。

7. 三个高频说法落地：理解、推理、生成各指什么​

日常说法在机制上更稳的表述你对外怎么讲（不玄学）
理解上下文注意力层把全序列中相关部分做了可权的混合，后续 FFN/更高层压缩成利于下一步预测的表示“不是读心，是有容量上限的序列建模；喂什么偏什么，超窗就截断/摘要/检索”
逻辑推理多数情况下是训练分布里的链式续写 + 多步自回归；在提示（如 CoT）下把中间步骤外显可提高稳定性“像推理的表现来自模式+长下文续写；硬逻辑/符号证明不保证，关键结论要工具/程序/数据校验”
生成显式的 自回归循环 输出子词，直到长度或 EOS“生成 = 反复 next-token；温度/top-p 在调随机性；流式=循环逐步返回”

这些表述与 LLM基础 里“降幻觉/工具替代猜测/二次校验”是同一条产品逻辑：用工程手段补齐模型机制上不设保证的地方。

8. 一张总览图（Mermaid）​

现代 Decoder-only 一次前向在算「下一 Token 分布」时的结构直觉（简化，用于建立心智模型）：

注：多轮对话、系统提示、RAG 证据，在工程上都先被 拼成一条（或多条后拼接）的上下文，再分词、再过同一套块；没有魔法抽屉单存“你的业务状态”，除非你在 Prompt 里显式写清或用工具回注。

9. 延伸阅读与你在工程里最该记住的点​

  • 要深入数学：以 “Attention is All You Need” 为起点，但面试/协作通常只需 QKV 角色 + 自回归解码循环 + 子词 三件套。
  • 要看更完整的原理线（预训练/采样/分词与 API 计费、能力边界等）：大语言模型工作原理（docs/AI/03-大模型技术/，与本文交叉引用对齐）。
  • 要落地到产品：LLM基础 的 Token 预算、温度、RAG、Prompt工程 的约束写法，和本文是同一条线的两侧。
  • 三句工程口诀：
    1. 一切靠上下文：Context Window 内、有序 Token。
    2. 生成就一条循环：next token，流式=循环向外露。
    3. 事实与硬逻辑不托管：工具、检索、程序、校验。

若你希望与训练侧衔接，可继续读 微调基础与常见范式（同一目录下 08- 为兄弟模块）。